Overview

Domino policies provide a powerful way for an administrator to manage their enterprise. But when multiple policies apply to a given user, it can be confusing to understand how the effective policy is determined. This article will explain in detail the factors that determines how policy precedence works.

First there are hierarchies for organizations and groups. There are three levels of policies: explicit, group (dynamic), and organizational. There are also the Inherit/Enforce settings which come into play. Lastly, there are the precedence settings for group policies. We will examine each of these factors in turn. But first, a qualification. Precedence does not mean that one policy completely overrides another. Precedence applies on a per field basis. So a setting in a policy with lower precedence can still make into the effective policy if the policy with a higher precedence does not have a value for that setting.

Hierarchies

Before explaining about the three levels of policies, the first thing that we need to understand is hierarchies. Organizational policies and dynamic polices (because of the group name, "Executives/IBM") can be hierarchical. When hierarchies are present, they are resolved first before precedence is applied.
Take for example the organizational policy "*/Europe/IBM", it is a hierarchical name. If there is also a root organizational policy, "*/IBM" then it would have to be taken into account. So resolving these two policies would result in the following table with some settings/values from the Mail settings for illustrative purposes:

	Required Change Interval	Assigned vault	Warning Period	Allowed Grace Period
Organizational: */Europe/IBM	Don't Set	N/A	14 days	90 days
Organizational: */IBM	90 days	N/A	21 days	N/A

Note: Don't Set in the above example and the rest of this document refers to the How To Apply feature of policies that exists on a per setting basis: That feature will be discussed in another Wiki since it is has a different dynamic in the policy space. For this discussion, having Don't Set for a value means that checkbox is selected. N/A simply means that the value does not matter.

As will we discuss in more detail in a moment, the more specific a policy is it takes precedence. So in the case of the two organizational policies above, the settings in the more specific policy */Europe/IBM will always take precedence over the more general settings of */IBM which results in an organizational effective policy of:

Effective policy

90 days

N/A

14 days

90 days

So after any organizational and group hierarchies are resolved, the precedence among the levels can now be determined.

The Three Levels

The precedence of the three levels is defined by there specificity. The more specific or narrowly defined the scope of a policy's assignment, the higher precedence it has. The least specific policy level is the organizational policy, i.e. "*/IBM". This policy applies to everyone that was registered by that organizations certifier and so has a wide scope. If you think of scope as a room full of people at conference, it would be like telling everyone to sit down. A more specific policy is the dynamic group policy, i.e. "Executives", where the user gets the policy because they are a member of a group. This will in general have a much smaller scope therefore it has higher precedence. Going back to the audience analog, it would be the same as telling everyone in the front row to stand up. The most specific policy is the explicit policy, i.e. "Relaxed Logins" that a user gets by either having the policy set in their person document. This kind of policy has the highest precedence. Using the audience analogy, it would be like telling Bob Smith to present the people in the first row who are standing an award certificate. So in decreasing order of precedence it is:
Explicit
Dynamic
Organizational

In order to continue the discussion, it will be useful to have some example policies. So for each of the three levels, here is a sample policy that contains only a few settings. Assume that these are the only settings that have been set. In red are the items that have precedence and are thus included in the effective policy:

	Required Change Interval	Assigned vault	Warning Period	Allowed Grace Period
Explicit: "Relaxed Logins"	120 days	Don't Set	Don't Set	120 days
Dynamic: "Executives"	Don't Set	/ExecutivesVault	Don't Set	Don't Set
Organizational: */Europe/IBM	90 days	N/A	14 days	90 days

So if a user had all of these policies assigned to them, the resultant effective policy would be:

	Required Change Interval	Assigned vault	Warning Period	Allowed Grace Period
Effective policy	120 days	/ExecutivesVault	14 days	120 days

How Enforce and Inherit change the rules

For every setting that is specified you can also choose whether to Enforce the setting in a child policy or Inherit that setting from a parent policy. Whereas precedence is based on specificity, the Enforce and Inherit settings are based on scope which is the opposite of specificity. When either of those options are used, the policy with the greater scope wins. Therefore the three levels as listed before has decreasing specificity but increasing scope. Taking the sample above but this time with one setting being enforced and another setting being inherited:

	Required Change Interval	Assigned vault	Warning Period	Allowed Grace Period
Explicit: "Relaxed Logins"	120 days	Don't Set	Don't Set	120 days, INHERIT
Dynamic: "Executives"	N/A	/ExecutivesVault	Don't Set	Don't Set
Organizational: */Europe/IBM	90 days, ENFORCE	N/A	14 days	90 days

So if a user had all of these policies assigned to them, the resultant effective policy would be:

	Required Change Interval	Assigned vault	Warning Period	Allowed Grace Period
Effective policy	90 days	/ExecutivesVault	14 days	90 days

The effect of using the Enforce option on a setting is pushing it up to the top the precedence hierarchy. The effect of using the Inherit option on a seting is to pull up a setting from a lower level. In the case of the Allowed Grace Period setting, if there had been no value in the organizational policy, then the setting of 120 days would used. So it will only inherit a value if it is present. It would not inherit an empty value.

Group Precedence

A user can only have one explicit policy or one organizational policy, but they since they can be in several groups they could have multiple dynamic policies. In that case the group precedence is used. The precedence is defined in the Domino Directory under People -> Policies -> Dynamic Policies:

It can also be seen but not modified in the Policy Precedence tab of a policy document itself:

Like how precedence works with the three levels of policies, precedence only comes into play when more than one policy has a value for a particular setting. Otherwise, the setting is just merged into the effective policy. Therefore if you do have two dynamic policies with the same setting, the one with the greatest precedence (the lowest numerical value) will win. When an effective policy is being created for a user, all of the dynamic group settings will be resolved before the precedence with explicit and organizational policies are resolved.

When a new dynamic policy is created, it will automatically be given the lowest precedence value. Using the screenshot example above, a new dynamic policy would be assigned a precedence value of 6. Then the actions buttons in the Domino Directory -> People -> Policies -> Dynamic Policies view can be used to increase or decrease precedence for a selected policy. This will move the policy up/down the list as appropriate and changing the precedence values relative to the other policies. If the policy with the highest precedence is deleted (3 in the example above) then the next lowest value ( 4 in the example above) becomes the highest precedence. Note the precedence values are not rebased in that case. So over time, the precedence values will drift higher.

Putting it all together

The table below shows all of the policies that effect a hypothetical user, Bob Smith. He has 5 policies: 1 explicit, 2 dynamic group, and 2 organizational policies. There is 1 setting with Enforce enable and 1 setting with Inherit enabled. The first 4 settings are from the Mail settings and the last one is from the Traveler settings document.

	Required Change Interval	Assigned vault	Warning Period	Allowed Grace Period	Low Battery Threshold
Explicit: "Relaxed Logins"	120 days	Don't Set	Don't Set	120 days, INHERIT	Don't Set
Dynamic: "Executives", Precedence 2	N/A	/ExecutivesVault	Don't Set	Don't Set	20%
Dynamic: "Mobil", Precedence 3	N/A	N/A	Don't Set	Don't Set	10 %
Organizational: */Europe/IBM	N/A	N/A	14 days	90 days	N/A
Organizational: */IBM	90 days, ENFORCE	N/A	21 days	N/A	N/A

The first step in determining the effective policy is to resolve the hierarchies of which there is only one in this example. */IBM and */Europe/IBM. Resolving that results in the next table:

	Required Change Interval	Assigned vault	Warning Period	Allowed Grace Period	Low Battery Threshold
Explicit: "Relaxed Logins"	120 days	Don't Set	Don't Set	120 days, INHERIT	Don't Set
Dynamic: "Executives", Precedence 2	N/A	/ExecutivesVault	Don't Set	Don't Set	20%
Dynamic: "Mobil", Precedence 3	N/A	N/A	Don't Set	Don't Set	10 %
Organizational	90 days, ENFORCE	N/A	14 days	90 days	N/A

In the above table, the "Enforce Password Expiration" is kept because of the Enforce setting. The Warning Period setting is kept because the "*/Europe/IBM" policy has higher precedence than "*/IBM".

The second step is to resolve the group precedence between the "Executives" and "Mobil" group. This results in the next table:

	Required Change Interval	Assigned vault	Warning Period	Allowed Grace Period	Low Battery Threshold
Explicit: "Relaxed Logins"	120 days	Don't Set	Don't Set	120 days, INHERIT	Don't Set
Dynamic	N/A	/ExecutivesVault	Don't Set	Don't Set	20%
Organizational	90 days, ENFORCE	N/A	14 days	90 days	N/A

In the above table, the "Low Battery Threshold" is kept because the "Executives" group has higher precedence than "Mobil".

Lastly, the precedence among the three levels needs to be resolved:

	Required Change Interval	Assigned vault	Warning Period	Allowed Grace Period	Low Battery Threshold
Bob Smith's effective policy	90 days	/ExecutivesVault	14 days	90 days	20%

Conclusion:
Hopefully, this article has been helpful in explaining how the different policies and the factors that effect them combine to form the effective policy for a user. In the future, look for other articles that take a different approach, namely, how to put together a combination of policies to solve different administrative scenarios. Also, in this article the How To Apply feature was not discussed. That is because it is somewhat different from precedence. Look for an article on that in the future.